Evolution of HTTP

Introduction#

HTTP is a widely used protocol, which directs the communication between clients and servers. This protocol was proposed and developed by Tim Berners-Lee in 1991. Over the years, this protocol has undergone many modifications that have made it feature-rich, flexible, and simple. In this lesson, we’ll compare different HTTP versions that enable us to choose a specific version for designing an API for a particular service. We discuss the following HTTP versions in the table below.

HTTP/0.9#

HTTP/0.9 was the initial version of HTTP. It was the simplest client-server and request-response protocol. This version of HTTP only had the support of the GET request method, and similarly, the response would consist of hypertext only. This version had no support for HTTP headers; as a result, this version couldn't transfer other content-type files. The connection would also terminate immediately after sending the response.

HTTP/1.0#

HTTP/1.0 was a browser-friendly protocol that supported HTTP header fields—including rich metadata—for requests and responses. As a result, the response was not limited to just hypertext, but could transfer other types of files, such as scripts, stylesheets, and media. HTTP/1.0 brought a number of changes to its infant version of HTTP/0.9. The HTTP/0.9 version's specification was about a page long; however, the HTTP/1.0 RFC came in at 60 pages. In comparison to HTTP/0.9, HTTP/1.0 had the support of three HTTP methods: HEAD, GET, and POST. Apart from the support of various HTTP methods, HTTP/1.0 used some ideas that we’re familiar with, for example, headers, response status codes, errors, redirection, conditional requests, and encoding.

The drawbacks of HTTP/1.0#

In HTTP/1.0, the notable flaws highlighted below had to be addressed:

• Non-persistent: An issue with HTTP/1.0 is its inability to keep the connection open between requests. The TCP connection would terminate after the client received the response to a single HTTP request. This approach is called non-persistent HTTP and it worked well in a world when a web page was typically just HTML text. The number of embedded links for resources like icons and other media content has increased significantly over time on the average web page. Non-persistence adds latency for the client, and in our world, many use cases need little to no latency for a better user experience. Let's understand this issue in detail, as given below.The following illustration shows the TCP three-way handshake required before the HTTP request is made. If a connection establishes and terminates after a request, the three-way handshake is repeated before making the next request. Therefore, HTTP/1.0 was not an efficient protocol for subsequent requests.

• Lack of host header: HTTP/1.0 had no mandatory host header in the request message. The host header identifies the target domain name to whom the request is made. If more than one website is hosted on the same server (virtual hosting), this header enables the server to identify the website easily.

• Limited caching headers: HTTP/1.0 performs cache revalidation using the If-Modified-Since header.

HTTP/1.1#

HTTP/1.1 came with a tremendous amount of features and options that overcame the drawbacks of the previous versions—HTTP/0.9 and HTTP/1.0. Due to the flaws mentioned above, there was a need for a major revision in HTTP/1.0. In this regard, HTTP/1.1 was proposed, which came with many features that are defined in RFC 2616. The following notable changes are made to the HTTP/1.1 to overcome the drawbacks of the HTTP/1.0 protocol.

• Persistent connection: Unlike HTTP/1.0, HTTP/1.1 now enables persistent connection. In HTTP/1.1, we may create a TCP connection, submit a request, receive a response, and then send more requests, all while receiving more responses. Another name for this strategy is connection reuse. The relative overhead caused by TCP is decreased per request by spreading out the setup cost, startup, and release over many requests.
  The process of connection reuse is demonstrated in the following figure:

• Pipelining: It’s also possible to pipeline requests, which enables sending multiple (inflight) requests before the arrival of the responses of earlier requests. This approach decreases the client's perceived latency and increases the system's performance.

• More HTTP methods: HTTP/1.1 is the most commonly used version that supports multiple HTTP methods, including HEAD, GET, POST, PUT, DELETE, TRACE, and OPTIONS .

• The Host header: HTTP/1.1 has made the Host header mandatory, which is included by default in the request.

• Virtual hosting: Virtual hosting enables a web server to host multiple websites using a single web server. It wasn't available in HTTP/1.0 because the marketplace would be simpler with static web pages. But as the demand to economically serve many websites from a single server grew, HTTP/1.1 added the needed support. This feature is now provided in HTTP/1.1 via the Host HTTP header, allowing the server to determine the website a request is intended for.
  The advantage of virtual hosting is that it enables web hosting companies to offer services at a lower cost by hosting multiple websites on a single server.

• The Upgrade header: HTTP/1.1 has the ability to upgrade the already established client-server connection to a new protocol via the Upgrade header. For example, the protocol can be upgraded to HTTP/2.0 or HTTPS after making a connection with the server.

• Transfer-Encoding: HTTP/1.1 provides a way to send specific commands to any proxies between the client and the server via a mechanism called transfer encoding. However, we won’t be relying on it in this course because this mechanism can be taken advantage of by a malicious or buggy proxy and can make debugging of any occurring issues difficult.

• Additional cache headers: HTTP/1.1 has advanced headers to control cache revalidation.

HTTP/2.0#

The Web has used HTTP/0.9 and HTTP/1.0 from the beginning; however, HTTP/1.1 was developed in 2007 and became a little outdated in terms of its services by 2012. Therefore, IETF established a working group to develop HTTP/2.0. The starting point was a technology called SPDY that Google had developed before. In May 2015, the finished product was released as RFC 7540.

The primary focus of HTTP/2.0 was to maintain backward compatibility; therefore, the headers, URLs, and general semantics didn't change much. Any new application could use HTTP/2.0 to benefit from the latest features, while the existing applications could still operate on HTTP/2.0 using limited features because of backward compatibility. The main features of HTTP/2.0 are the following:

• Prioritized responses: In the older HTTP/1.1, multiple requests over a TCP connection are sent in a pipeline where the responses from the server are received in the order the requests were sent. On the other side, in HTTP/2.0, many requests can be sent, and the server responds in any order based on the priorities of the requests. For example, if there are requests for two different images, the server sends the small image first. When the browser starts displaying the small image, the second image is sent to the client. This feature of HTTP/2.0 is called multiplexing, in which the responses can arrive in any order.

• Server push: In HTTP/2.0, a server can send resources to the client that might be needed on the client-side prior to the client's request for the resources. This mechanism is called a server push. For example, if a client requests a web page and the server knows that it needs other resources, such as style sheets and script files, the server sends these resources prior to the request from the client.

HTTP/3.0#

HTTP/3.0 was a major revision in HTTP that was created by complementing the commonly used HTTP/1.1 and HTTP/2.0. The primary difference between HTTP/2.0 and HTTP/3.0 is the transport protocol that is used to support HTTP messages. The previous version relied on the Transmission Control Protocol (TCP). However, HTTP/3.0 utilizes QUIC (Quick UDP Internet Connections) on top of User Datagram Protocol (UDP). The main features of HTTP/3.0 are:

• Adoption of QUIC protocol: Multiplexing of streams and per-stream flow control is provided by QUIC, a transport protocol. It has the capacity to enhance HTTP performance in comparison to TCP mapping by offering stream-level reliability and congestion control throughout the connection.

• TLS 1.3: HTTP/3.0 also implements TLS 1.3 at the transport layer, providing similar security and integrity to running TLS over TCP.

• Improved performance: HTTP/3.0 has lower latency and high reliability due to the adoption of the QUIC protocol. In some studies, HTTP/3.0 is faster than HTTP/2.0.

• Avoids head-of-line blocking: It also addresses a major problem in HTTP/1.1 and HTTP/2.0, known as head-of-line blocking.

The following figure shows the HTTP/3.0 protocol stack:

The following table summarizes the differences between different versions of HTTP:

Summary#

In this lesson, we discussed various versions of the HTTP protocol, including HTTP/0.9, 1.0, 1.1, 2.0, and 3.0. We presented the pros and cons of each protocol that will help us select a specific HTTP version for a particular service in the upcoming chapters.